Apparatuses, Methods and Systems for Computer-Based Secure Transactions

ABSTRACT

The systems, methods and apparatuses described herein provide a computing environment for completing a secure transaction. An apparatus according to the present disclosure may comprise a screen, a first switching device coupled to the screen, an input device, a second switching device coupled to the input device, a non-secure processor, a secure processor and a credit card reader operatively coupled to the secure processor. The non-secure processor may generate a message containing a purchase transaction request. The secure processor may receive the message, assume control of the screen and input device while the apparatus is operating in a secure mode, establish a secure connection with a server, receive payment information to be submitted to the server, digitally sign certain transaction information and submit the digitally signed certain transaction information to the server to complete the secure transaction.

RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.13/861,701 (the '701 application), entitled Apparatuses, Methods andSystems for Computer-Based Secure Transactions,” filed Apr. 12, 2013.The '701 application claims priority to U.S. Provisional Application61/623,702 (the '702 application), entitled “Apparatuses, Methods andSystems for Computer-Based Secure Transactions,” filed Apr. 13, 2012.The content of each of '701 and '702 applications is incorporated hereinby reference in their entirety.

FIELD OF THE DISCLOSURE

The systems, methods and apparatuses described herein relate to thesecurity of computer network-based commercial and other sensitive datatransactions.

BACKGROUND

Internet shopping, online banking, and other network-based forms oftransmitting sensitive data are highly popular, but may be susceptibleto a variety of security breaches resulting from computer viruses,backdoors, keyloggers and other forms of attacks on the user's computeror other consumer transaction device. These attacks generally relate tovulnerabilities in the operating system and/or application programsexecuting in the device that are used to access or communicate throughthe network.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary system according to thepresent disclosure.

FIGS. 2A-2B represent a flow diagram of an exemplary method according tothe present disclosure.

FIG. 3 represent a flow diagram of another exemplary method according tothe present disclosure.

FIG. 4 is a block diagram of another embodiment according to the presentdisclosure.

DETAILED DESCRIPTION

Certain illustrative aspects of the systems, apparatuses, and methodsaccording to the present invention are described herein in connectionwith the following description and the accompanying figures. Theseaspects are indicative, however, of but a few of the various ways inwhich the principles of the invention may be employed and the presentinvention is intended to include all such aspects and their equivalents.Other advantages and novel features of the invention may become apparentfrom the following detailed description when considered in conjunctionwith the figures.

In the following detailed description, numerous specific details are setforth in order to provide a thorough understanding of the invention. Inother instances, well known structures, interfaces, and processes havenot been shown in detail in order not to unnecessarily obscure theinvention. However, it will be apparent to one of ordinary skill in theart that those specific details disclosed herein need not be used topractice the invention and do not represent a limitation on the scope ofthe invention, except as recited in the claims. It is intended that nopart of this specification be construed to effect a disavowal of anypart of the full scope of the invention. Although certain embodiments ofthe present disclosure are described, these embodiments likewise are notintended to limit the full scope of the invention.

The apparatuses, methods and systems according to the present disclosureprotect online sale transactions against operating system and othersoftware-based vulnerabilities within a consumer transaction device.

FIG. 1 shows one exemplary embodiment of a system according to thepresent disclosure. The system may first comprise one or more consumertransaction devices 180, i.e., any device from which a user may make apurchase from an e-commerce site, conduct banking transactions, orotherwise complete a network-based transaction for which it would bedesirable to have increased security. Such a consumer transaction device180 may be, for example, a desktop computer, a laptop, a tabletcomputer, a smart phone, a TV set, etc.

As will be described in greater detail below, the consumer transactiondevice 180 may operate, at any given time, in one of at least two modes:a non-secure mode and a secure mode. The secure mode may be usedwhenever the consumer transaction device 180 needs to communicate in asecure manner with an e-commerce web site, a bank or financialinstitution web site, database, or any other software running on aremote computer or collection of computers.

To support these at least two modes of operation, the consumertransaction device 180 may first comprise hardware componentstraditionally included in a computing device to effectuate a non-securemode of operation, such as a processor 110, memory 115, communicationsport 118, etc., and traditional input/output devices such as a keyboard192 and a screen 123. It is to be recognized that other forms of inputor output devices may also be used such as a mouse and/or an infraredcontroller with a matching infrared receiver. In the non-secure mode,these components may be controlled by an operating system 111 and/or oneor more applications 112, stored within memory 115, and running on theprocessor 110. As the operating system 111 and applications 112 aresusceptible to hacking by a malicious party, they are consideredinsecure for the purposes of the present disclosure and accordingly areshown within the “non-secure zone” 189 indicated by the dashed lines.

The consumer transaction device 180 may further comprise a second set ofhardware components enabling a secure mode of operation including, butnot necessarily limited to, a secure processor 121, secure volatilememory 125, root certificate storage 126 (which may be implemented, forexample, as a read-only, non-volatile memory), a credit card reader 191(e.g., a magstripe and/or smartcard/ICC reader), a keyboard switch 194,an image processor 171, a mixer 181, and a mechanism for indicating to auser when the consumer transaction device is operating in a secure mode,shown on FIG. 1 as “indicator” 193. Such an indicator 193 may be, forexample, a green LED which is placed on an outside case of the consumertransaction device 180 and readily visible to a user. In someembodiments, the secure processor 121 may be implemented as software ona generic CPU and may have its own operating system (not shown); in someembodiments, the secure processor 121 may be implemented completely inhardware.

In a non-secure mode, the keyboard switch 194 may operationally connectthe keyboard 192 to the operating system 111, the indicator 193 shouldbe turned off, and the mixer 181 may pass all display related signals,commands and/or data from the operating system 111 to the screen 123. Ina secure mode of operation, the keyboard switch 194 may operationallyconnect the keyboard 192 to the secure processor 121, the mixer 181 maypass the signal from the image processor 171 to the screen 123, and thesecure processor 121 may cause the indicator 193 to turn on or otherwisebecome active. In this manner, the same input/output devices (e.g., thekeyboard 192 and screen 123) may be used to support both the non-secureand secure modes of operation.

According to this embodiment, the components enabling the secure modemay be operationally separated from the components used in non-securemode. Accordingly, interactions and/or communications between theoperating system 111 (and any applications 112 which are running underit) on the non-secure side and any applications or operations running onthe secure processor 121 shall be restricted to a set of limited andwell-defined operations, such as passing purchase requests from theoperating system 111 to the secure processor 121, and passing the resultof purchases from the secure processor 121 back to the operating system111, as described below.

Additionally, when the consumer transaction device 180 is operating in asecure mode, the image processor 171, the mixer 181, the indicator 193,and the keyboard switch 194 shall be under direct control of secureprocessor 121 (or another component within the secure zone ofoperation), i.e., the operating system 111 (or applications 112) have nocapability to affect their operation when the consumer transactiondevice is in a secure mode. This may be achieved, for example, byimplementing the secure processor 121 (and other components within thesecure zone) on physically separate hardware. In an alternativeembodiment, the secure and non-secure modes of operation may beimplemented on one or more common set of hardware components byutilizing virtualization techniques. For example, in one embodiment thesecure processor 121 and processor 110 may be implemented on the samephysical CPU as long as virtualization guarantees a logical separationbetween the two processors that is equivalent to physical separation.

Also as shown on FIG. 1, the consumer transaction device 180 maycommunicate with one or more servers 100 to and from which the consumertransaction device may communicate sensitive and/or private information.The server 100 may, for example, host an e-commerce site, a bank website, a database, or some other form of remotely-accessible softwareand/or data. In general, and not by way of limitation, the server 100may comprise a crypto engine 102 for encrypting and decryptingcommunications with the consumer transaction device 180 and acommunications port 104 suitable for communicating with thecommunications port 118 of the consumer transaction device 180. In someembodiments, the server 100 may be implemented using one or morephysically distinct computers (for example, using a load balancer), andmay comprise one or more crypto engines 102.

FIGS. 2A-2B and FIG. 3 depict exemplary methods for processing onlinesales or other transactions according to the present disclosure. FIGS.2A and 2B focus on information flow from the perspective of a consumertransaction device 180, while FIG. 3 focuses at a higher level on theinformation flow among a consumer transaction device 180, a server 100,and one or more financial institutions associated with the user of theconsumer transaction device 180.

As shown on FIG. 2A, at step 205, the secure processor 121 may receive amessage containing a purchase transaction request. This message may havebeen generated by the non-secure zone 189, for example, in response to auser clicking the “check-out” button on a webpage; it may include theURL (or other identifier) of an internet resource which will participatein the processing as described below; in some embodiments, if an HTTPURL is used, it may also additionally include any relevant HTTP headers,and/or any associated cookies.

As a result, at step 210, the secure processor 121 may start the secureoperation of the consumer transaction device 180 by assuming controlover the screen 123 and keyboard 192. To do this, the secure processor121 may send instructions to the keyboard switch 194 to operationallydisconnect the keyboard 192 from the non-secure components and tooperationally connect it to the secure processor 121; and may furthersend instructions to the mixer 181 to display images from the imageprocessor 171 instead of the processor 110 (to ensure that the operatingsystem 111 no longer has control of the screen 123).

Additionally, to provide an affirmative confirmation to the user thatthe system is operating in a secure mode, the secure processor 121 maycause the indicator 193 to turn on or otherwise become active. In asecure mode of operation, no information relating to the securedtransaction may be accessible (except perhaps in an encrypted form) toany of the non-secure components, such as the non-secure processor 110,operating system 111 and/or any of the applications 112. In other words,a “virtual computer” may be formed at this point, comprising a secureprocessor 121, a keyboard 192, a screen 123, a card reader 191, and anyother components necessary to implement the virtual computer. This“virtual computer” may be self-contained and self-sufficient (meaningthat it does not depend on non-secure zone 189 to complete itsoperations) except that, as described in further detail below, it mayuse the non-secure zone's network transport facilities (e.g., a TCP/IPstack) to communicate with the server 100. Nevertheless, to the extentthat any information, data and/or messages are provided from any securecomponents to the non-secure zone 189 (e.g., to be transmitted to theserver 100 using the TCP/IP stack of the operating system 111), thatinformation, data and/or messages may be in an encrypted format whereinthe operating system 111 and or any applications 112 running under it donot have the capability to decrypt the information.

At step 215, the secure processor 121 may start establishing a secureconnection with a server 100 of the selling entity (e.g., an e-commerceweb site) using the URL received from the non-secure components of theconsumer transaction device 180. By way of example and not limitation,the secure connection may be an HTTPS (HTTP over SSL) connection. Asnoted previously, in communicating with the server 100 over the secureconnection, the secure processor 121 may use the network transportcapabilities of the operating system 111 running on the non-secureprocessor 110. In such an embodiment, the operating system 111 actsmerely as an intermediary to transmit the secure SSL messages withoutthe capability to determine and/or alter the content of the SSLmessages. In one embodiment, for example, the operating system 111 maybe responsible for implementing TCP/IP communications while the secureprocessor 121 may be responsible for processing the “payload” that iscommunicated over the TCP/IP connection. In another embodiment, theoperating system 111 running on the non-secure processor 110 may beresponsible for implementing the first four layers of the open systemsinterconnection (OSI) model (i.e., the physical layer, data link layer,network layer and transport layer), while the secure processor may beresponsible for implementing layers five through seven (i.e., thesession layer, presentation layer and application layer). It is to berecognized that other similar models of separating the processing amongthe operating system 111 and the secure processor 121 are also withinthe scope of the present disclosure, as long as cryptographic processingstays within the secure processor 121. In this manner, the operatingsystem 111 cannot “eavesdrop” or affect the SSL messages (or otherencrypted messages) between the secure processor 121 and the server 100.In an alternative embodiment, the secure processor 121 may implement theentire TCP/IP stack or the entire OSI model such that it may directlyuse the communication port 118 to communicate with the server 100.

Optionally, in the process of establishing a secure encrypted channel,the secure processor 121 may authenticate itself to the server's cryptoengine 102 (for example, by using an SSL client certificate, or bysending to the crypto engine 102 a message signed by a key that isspecific to the secure processor 121 of the transaction device 180).

At step 220, the server 100 may send a response to the secure processor121 of the consumer transaction device 180 acknowledging the request toestablish a secure encrypted channel (in this example, an SSL channel).The consumer transaction device 180 may then establish the securechannel (in this example, an SSL channel) between the crypto engine 102of the server 100 and the local device's secure processor 121.

In the process of establishing the secure encrypted channel, the cryptoengine 102 of the server 100 may authenticate itself to the consumertransaction device 180 using a digital certificate. For example, eachserver 100 may have a private key and a corresponding digitalcertificate which has been signed by a “root certificate” belonging to arecognized and well-respected certificate authority. The secureprocessor 121 may have already stored a copy of this root certificate incertificate storage 126, or may have an alternative mechanism (forexample, by storing the public key of the certificate authority insteadof the root certificate) for verifying that the provided digitalcertificate is legitimate. It will be understood that multiple “rootcertificates” and more elaborate public key infrastructure (PM) schemas,as well as alternative schemas for signature validation (such as thesimple public key infrastructure (SPKI), simple distributed securityinfrastructure (SDSI) or pretty good privacy's (PGP's) “web of trust”)are also possible within the scope of present disclosure.

In some embodiments, the server's certificate may differ slightly from atraditional certificate, such that it contains not only a text entrycapable of identifying the certificate owner (usually the “CN” field ofan X.509 digital certificate), such as the name of the merchantassociated with the server 100, but may further contain an image (forexample, PNG or JPEG) with a visual representation of the identity ofthe certificate owner. This image may be a part of the digitalcertificate in the sense that it may be encompassed by the signature ofthe certificate issuer in the same way that the other fields of thecertificate are encompassed; for example, if an X.509 certificate isused, such an “identity image” may be included in an “Extension” fieldof the X.509 certificate. As will be described in further detail below,in some embodiments, it may also be desirable to show this “identityimage” on a pre-designated portion of the screen 123 during the entiretime that the consumer transaction device 180 is operating in a securemode and communicating with the server 100.

At step 225, the secure processor 121 of consumer transaction device 180may receive the certificate of the server 100 and verify itsauthenticity using a root certificate accessible to the secure processor121 (e.g., stored in root certificate storage 126). If, at step 230, thecertificate is found invalid, the transaction may be stopped.

Otherwise, at step 235, the secure processor 121 may instruct the imageprocessor 171 and mixer 181 to display the certificate to the user. Forinstance, when the secure processor 121 extracts an identity image fromthe certificate, it may pass the image to the image processor 171 forany necessary processing or rendering, and then the image may passthrough the mixer 181 for display on the screen 123. To enhancesecurity, in one embodiment, the identity image may be displayed on apredefined or predesignated area of the display 123 until thetransaction is completed or aborted. Alternatively or additionally, thename of the entity operating the server 100 may be displayed on thescreen 123 until the transaction is completed or aborted.

At step 240, the secure processor 121 may receive transaction detailsfrom the server 100 and display them to the user. By way of example andnot limitation, the secure processor 121 may receive HTML code (and/orother code, such as JavaScript) that, when processed by the secureprocessor 121, renders a web-based form for displaying and/or completingthe transaction details. The secure processor 121 (with or without theaid of the image processor 171, depending on the specific implementationand the capabilities of the processor 121) may execute the receivedcommands, information and/or code, and then an image of the form maypass through the mixer 181 for display on the screen 123. In analternative embodiment, and assuming that the secure processor 121 hasminimal processing capabilities such that it cannot execute JavaScriptand/or render HTML to render a screen displaying transactioninformation, the secure processor 121 may receive an image (e.g., a PNGor JPEG) containing the relevant transaction information in apre-rendered format. When the secure processor 121 receives such animage, it may pass the image to the image processor 171 for rendering,and then the image may pass through the mixer 181 for display on thescreen 123.

Optionally, if the secure processor 121 is capable of rendering at leastdigits and currency symbols, in addition to the image, information suchas currency and the amount of payment may be communicated to the secureprocessor 121 in digital form. In such an embodiment, information may berendered and displayed to the user, for example, in a second designatedarea of the screen 123.

If, at step 245, the information displayed on the display 123 does notcorrespond to the user's expectations (for example, a valid certificatefor “XYZ, Inc.” is displayed where the user expected to see thecertificate for “Amazon.com”), the user may stop the secure transactionprocessing (for example, by pressing a predefined button on keyboard192). If the displayed certificate aligns with the user's expectations,the method may proceed to step 250.

If, at step 250, the transaction details (for example, the amount to bepaid and/or the purpose of the payment) do not correspond to the user'sexpectations (for example, instead of the intended $5 for stationery theuser is about to transfer $5,000 to the personal account of a person shedoes not know), the user may elect to terminate a suspicioustransaction. Thus, according to the present disclosure, beforecompleting the transaction, the user may confirm that the informationreceived from the server 100 is genuine and the channel is secure bychecking that the indicator 193 is on and that the transactioninformation displayed on the screen 123 (such as the identity image,transaction amount and the purpose of the payment) corresponds to theuser's expectations for this transaction. If the information displayedon the screen 123 does not match the user's expectations—e.g., thepayment amount is incorrect, or the identity image is not displayed—theuser may terminate the transaction before any payment or paymentauthorization is transmitted to the server 100.

At step 255, the user may enter any information that may be necessary tocomplete the transaction. For example, the user may be requested toinsert a credit card into the card reader 191 (and optionally enter aPIN number on the keyboard 192 or a separate keypad (not shown)) and toconfirm that she consents to the transaction as it is displayed.

In one embodiment, at step 260, if a PIN has been entered, the secureprocessor 121 may verify the PIN. This verification may be implementedas either an “offline PIN” verification wherein the PIN is verifiedagainst information stored on the card itself, or as an “online PIN”verification wherein the secure processor issues a request to a paymentnetwork of one or more financial institutions (via server 100) to verifythe PIN.

In one embodiment, at step 265, if (i) the card reader 191 is capable ofreading an ICC, (ii) the card inserted into the reader 191 is an ICC,and (iii) the merchant has indicated that it is willing to process ICCtransactions, the secure processor 121 may initiate the process of usingthe ICC to digitally sign certain transaction information. To do so, thesecure processor 121 may request that the ICC generate a message(similar to an authorization request cryptogram (ARQC) as used in theEuropay, MasterCard and Visa (EMV) global standard for interoperation ofICCs) that contains a cryptographic message authentication code (MAC)encompassing certain portions of that message. This message may includeinformation about the currency and amount of the transaction (which arenormally present in an ARQC message), and additionally may include ahash of the transaction details (e.g., from step 240), and a hash of theidentity of the merchant as it was presented to the user (e.g., from themerchant certificate, as it was shown to the user). Instead ofincorporating a hash of certain information, the message may insteadinclude the actual information (e.g., instead of a hash the merchantidentity, the actual merchant identity). Additionally, the credit cardPIN, the transactional details and/or the identity of the merchant (ortheir respective hashes) may be taken into account when calculating theMAC to ensure the integrity of the transactional details and/or themerchant's identity. It will be understood, however, that while thecredit card PIN is used for the calculation of the MAC, the credit cardPIN itself should preferably not be included in the message, so itremains inaccessible for unintended parties (such as, for example, themerchant).

It is to be recognized that the actual information that is digitallysigned may vary based on the specific embodiment implemented and thatthe examples herein are not intended to be limiting. For example, in anembodiment in which an image is displayed to the user, the hash of thatimage may be included in the digital signature. As the digital signaturemay contain exactly the information that was shown to the user, it maybe seen as a signature under contract which is formed between the userand the merchant at the moment of purchase, and may later be used fordispute resolution purposes. Additionally, it is to be recognized thatother methods of digital signatures—for example, based on public/privatekey cryptography—may be used instead of or in addition to the MAC. Ifpublic/private key cryptography is used, in some embodiments the messagemay contain two separate signatures—one signing all fields except forthe PIN, and another signing the PIN (with, potentially, a random saltadded). Such an approach will allow the merchant to validate a digitalsignature itself without compromising the PIN.

Once the message has been signed, it may be sent to the merchant'sserver 100 for processing.

When the transaction is complete, at step 270, the secure processor 121may disconnect from the server 100 (or at least terminate the secureconnection to the server 100) and revert back to the non-secure mode ofoperation.

After the secure mode of operation has terminated, the secure processor121 may cause the indicator 193 to turn off or otherwise be inactive,and may instruct the keyboard switch 194 and the mixer 171 to switchback to non-secure mode, i.e., to process keyboard 192 input and screen123 output through the operating system 111. Additionally, the secureprocessor 121 may pass information about the outcome of the transactionback to operating system 111 for further processing. For example, thesecure processor 121 may pass back to the operating system the URL ofthe web page that indicates whether the transaction was successful ornot. This page may be shown in the web browser and may provide, forexample, a transaction reference number that the user may elect to saveand/or print, and it may also include different links depending onwhether the transaction was successful or not.

As noted previously, FIG. 3 focuses on an exemplary information flowamong a consumer transaction device 180, a server 100, and one or morefinancial institutions associated with the user of the consumertransaction device 180 during an online purchase transaction.

At step 300, a user of the consumer transaction device 180 may select aproduct or service to be purchased from a web site hosted on server 100.This may happen, for example, while the consumer transaction device 180is in a non-secure mode and the user is browsing the Internet using aweb browser running as one of the applications 112 under the operatingsystem 111. When the user is ready to engage in a secure transaction(e.g., complete a purchase), at step 305, the non-secure components ofthe consumer transaction device 180 may pass secure transactionprocessing to the secure processor 121. This may occur, again, forexample, by having the non-secure components transmit a purchase request(for example, the URL of the Internet resource as described in greaterdetail above) to the secure processor 121.

At step 310, the secure processor 121 may process the transaction andsend the (optionally signed) message to the merchant, e.g., as describedwith respect to steps 205-270 on FIG. 2.

At step 315, the merchant may receive the message formed by the customertransaction device and may verify that the amount of the transaction,the supplied currency, and the hash of the merchant ID and transactiondetails (which in some embodiments may, as it was described with respectto step 265, be represented as their actual values) are consistent withwhat the merchant expects to be signed by the user. If, at step 320, themerchant determines that the received values are not the same asanticipated by the merchant, the merchant may select to decline thetransaction as based on inconsistent information and potentiallyfraudulent or otherwise unauthorized. If, however, the received valuesare as expected, at step 325, the merchant may save a copy of themessage for any potential future dispute resolution, and may transmit acopy of the message to the user's bank or financial processor forfurther transaction processing.

It should be noted that if the MAC is used as a digital signature, themerchant will not be able to verify that the signature is valid;nevertheless, the merchant may verify that fields other than the MAC inthe message are correct, as this may be important for dispute resolutionpurposes. In other embodiments, if public/private key cryptography isused for a digital signature, the merchant may be able to verify thedigital signature, and terminate the process if the signature isinvalid.

It will be understood that, while the merchant can verify whether theuser has initiated the transaction by using details previously specifiedby the merchant, the user's sensitive information (such as, for examplethe user's credit card PIN, and any other communications between theuser's transactional device and the bank) preferably are not accessibleby the merchant; this can be achieved, for example, by encryptingcorresponding parts of the message with the key(s) which are known toboth the ICC and the bank, but are not known to the merchant.

At step 330, the user's bank may receive the message from the merchant,verify the digital signature on the message (previously generated by thesecure processor 121 at step 265), and perform any other appropriateapproval procedures. For example, the user's bank may verify whether theuser has sufficient funds to perform the transaction. If signatureverification fails, or the user has insufficient funds, the bank maydecline the transaction. It will be understood that, while the merchantmay not be able to verify the signature, an invalid signature of validdata will lead to a transaction decline. As a result, only transactionsfor which the integrity of their related data is proven, may beaccepted.

At step 335, the bank may respond to the merchant and provide atransaction status. If, at step 340, the bank has authorized thetransaction, at step 345, the merchant may store the bank confirmationfor future dispute resolution purposes, provide an order confirmation tothe user, and ultimately dispatch the purchased goods.

It shall be noted that even if the merchant was not able to validate theuser's signature at step 320, the merchant will have sufficientinformation for future dispute resolution purposes to prove that acontract was formed between the user (using his ICC) and the merchant,as well as the details of that contract, if (i) the merchant ensuredthat all of the fields in the message forwarded to the bank werecorrect, and (ii) the merchant has confirmation from the bank that thebank verified the ICC signature of the same message.

It shall be noted that the embodiment described above, whichincorporates identity images within the server's certificate, isdesigned to minimize the complexity of the secure processor 121 and theimage processor 171. In other embodiments, however, this is notrequired. For example, an alternative embodiment may use a textidentifier (e.g., the traditional “CN” field of an X.509 certificate).This will require either the secure processor 121 or the image processor171 to provide some font rendering capabilities in order to display theserver institution's name on the screen 123. In yet another embodiment,the server 100 may send HTML (or XML) page to the secure processor 121(which will be shown to the user and potentially signed by ICC). Thiswould require an appropriate rendering engine to be included into eitherthe secure processor 121 or the image processor 171.

It will be understood that, though the present discussion has focused oncommunication with an e-commerce web site, consumer transaction devices180 according to the present disclosure may interact with multipledifferent merchants, web sites, banks, and other institutions.

FIG. 4 is a block diagram of another embodiment according to the presentdisclosure in which the secure mode of operation capabilities discussedherein are integrated into a television set 400. The television set 400may comprise “traditional” components, such as a television tuner 410(including associated inputs 411 and antenna connections 412), atelevision signal parser 420, and a video signal processor 425. Thetelevision set 400 may further include a service information processor430, a teletext or subtitle processor 435, and a mixer 460, as well asother components (not shown) typically present in a television set.These components may be implemented as separate physical units, or maybe logical and/or functional blocks within one or more integratedprocessing units. Remote input 192A (for example, an infrared receiver)may be used to receive control signals from a remote control 192B (forexample, an infrared remote control) operated by a user. The visualoutput of the television set 400 may be displayed on the screen 123.

The television set 400 may receive (in a non-secure mode of operation)an input data stream and use the parser 420 to extract the informationcontent within that input data stream. In one mode of operation, forexample, the television set 400 may receive a television signal (forexample, an NTSC TV signal) at the television tuner 410 via the antenna412 and use the parser 420 to extract the informational content withinthat signal. The television signal may include video information, audioinformation, and/or service information. As discussed further, theservice information may be any of teletext information, subtitles and/orother types of information. In another exemplary mode of operation, thetelevision set 400 may receive through the external input 411 mediacontent in a compressed container bitstream format (for example, theMPEG-4 format). Again, the television set 400 may use the parser 420 toprocess the container bitstream and extract the various componentstreams contained within the container (for example, video, audio,subtitles, etc.).

After the input into the television set 400 has been parsed into itsvarious components, each component may be further processed according toits type. For example, video information may be processed using thevideo signal processor 425. If the video information is encoded in adigital format, for example, the video signal processor 425 may performvideo stream decoding. Service information, such as subtitleinformation, teletext and or advertising information, may be passed tothe service information processor 430 in order for it to determine thetype of service information at issue. Once the service informationprocessor 430 determines the type of service information, it may thenpass the information to one or more appropriate processors for furtherprocessing. For example, if the service information processor determinesthat the service information is teletext information or subtitleinformation, it may forward the information to the teletext and subtitleprocessor 435, and if it determines that the service information isadvertising information it may pass that to the advertising informationstream processor 450. In an alternative embodiment, the functionality ofthe service information processor 430 may be incorporated into theparser 420.

The teletext and subtitle information processor 435 may extract textand/or images that may be incorporated into a teletext and/or subtitleinformation stream and render the information into images that can becombined with the video information and displayed. In the example inwhich the TV receives an MPEG-4 container, for example, the subtitleinformation may be contained within its own distinct stream, which maybe extracted and decoded by the teletext and subtitle processor 435 andrendered as images.

Decoded video from the video signal processor 425 and rendered imagesfrom the teletext and subtitle processor 435 may then be mixed by themixer 460 to generate a resulting picture to be displayed on the screen123; for example, the mixer 460 may overlay semi-transparent subtitleimages coming from the teletext/subtitle processor 435 over renderedvideo stream coming from the video signal processor 425

The input data stream received by the TV 400 may also include an“advertising information” component. This advertising information may beincorporated into the service information. For example, the advertisinginformation may be encoded as teletext information, incorporated intothe subtitle stream of a media container bitstream (e.g., an MPEG-4container bitstream), or incorporated into its own distinct stream of amedia container bitstream. In one embodiment, when incorporated into amedia container bitstream, at the point when the video stream containsthe start of the video advertising sequence, the “advertisinginformation” stream may include a chunk comprising (i) a URLcorresponding to the video advertising sequence that has just started inthe video stream, and (ii) a duration for which this URL will be active(which may correspond to the duration of the video advertisingsequence).

The chunks of an advertisement information stream may have a predefinedstructure. For example, the content of each advertising informationchunk may include at least a URL (and, optionally, other associatedinformation) for an Internet resource to be used as described above, anda duration of the advertisement. To process advertisement informationstreams, the TV set 400 may have an advertisement information streamprocessor 450.

Further details regarding how the advertising information may beprocessed are provided below.

The television set 400 may further include a secure processor 121, acredit card reader 191, a remote input switch 194A, an image processor171, a mixer 181, a communication port 118 and an indicator 193. Thesecomponents, as shown on FIG. 4, operate in a similar manner to the samecomponents shown on FIG. 1. Accordingly, the television set 400 may alsooperate in a secure mode, similar to that described with respect toFIGS. 1 and 2. Whether and when the television set 400 operates in thesecure mode may be controlled by the secure processor 121.

In the exemplary embodiment shown on FIG. 4, a user may use the remotecontrol 192B to provide input to the television set 400. The user'scommands, as inputted into the remote control 192B, may be received bythe remote input receiver 192A and transmitted either to the secureprocessor 121 (if the television is operating in a secure mode) or tothe traditional components (if the television is operating in anon-secure mode) via the input switch 194A.

In one embodiment, the television set 400 may receive an input datastream representing a product advertisement wherein the input datastream includes an advertising information component. The input datastream may be parsed and the service information processor 430 maydetermine that the advertising information component should be forwardedto the advertising information stream processor 450. The advertisinginformation stream processor 450 may extract a URL (and other associatedinformation, if any) from a correspondent portion of the advertisinginformation stream and may store it for later reference.

If a user presses a “buy” button 471 on the remote control 192B at thetime when information about the advertised product is being displayed onthe screen 123, the signal representing that action may be passed to theadvertisement information stream processor 450, which may then initiatea transition to the secure mode of operation by passing the currentlystored URL of the web site from which the product can be purchased (or aURL as processed below) to the secure processor 121.

In some embodiments, at the time that the URL is passed to the secureprocessor, the secure processor may also receive user information suchas the address of the user to which the purchased product should bedelivered. In one implementation, the secure processor 121 may providean interface through which the user may enter this address informationusing the remote control 192B. In another implementation, the user mayprovide the address information in advance, and that information may bestored in a non-volatile memory in the television set 400 for laterretrieval by the secure processor 121. In another implementation,assuming that the delivery address is the same as the billing address ofthe user with the Internet service provider (which is normally thecase), the secure processor 121 may request (for example, via thecommunications port 118) the billing address from the Internet serviceprovider (ISP) that provides the Internet service to which thecommunications port 118 is connected. The ISP may respond to the requestby providing the billing address information associated with the IPaddress from which the request came (noting that, from the ISP's pointof view, it can be either the IP address of the communications port 118,or the IP address of an intermediate router).

In yet another implementation, the cable TV service provider may embedaddress information into the TV signal as service information that canbe processed by the service information processor 430. For example, thecable TV service provider may embed state, city and/or zip informationcommon to a set of users which correspond to a particular “point ofpresence” for cable TV service providers, as well as a list of streetand building numbers within that common geographic location in the TVsignal. Then the user needs only to complete his address information byselecting the appropriate street and building number information fromthe available choices. Given appropriate capabilities, the cable TVservice provider may individually embed specific address information foreach TV that receives the TV signal.

Regardless of the manner in which the address information is received,it can be combined with the URL information extracted from the videostream to obtain a URL that contains the characteristics of the productbeing advertised and the delivery address. For example, if the user iswatching an advertisement for a local pizzeria advertising a pizzamargherita, and he presses the “buy” button 471 on the remote control192B while the advertisement is being displayed, the advertisinginformation stream processing unit 450 may obtain the URL associatedwith the currently displayed advertisement (for example,“https://www.pizza.example.com/?product=Pizza+Margherita”), combine thatURL with the delivery address information obtained according to one ofthe methods described above (for the purpose of the current example,assume it is “123 Main Street, Anytown, ST, 11111), to produce acombined URL (e.g., using standard URL encoding rules, this URL may be“https://www.pizza.example.com/?product=Pizza+Margherita&address=123+Main+Street%2C+Anytown %2C+ST %2C+11111”), and pass that combined URL to the secureprocessor 121.

When the appropriate URL has been created and passed to the secureprocessor 121, the secure processing components of the television set400 in the embodiment of FIG. 4 may interact with the server from whichthe product may be purchased in a manner similar to that described withrespect to FIGS. 1, 2A-2B, and 3.

While specific embodiments and applications of the present inventionhave been illustrated and described, it is to be understood that theinvention is not limited to the precise configuration and componentsdisclosed herein. The terms, descriptions and figures used herein areset forth by way of illustration only and are not meant as limitations.Various modifications, changes, and variations which will be apparent tothose skilled in the art may be made in the arrangement, operation, anddetails of the apparatuses, methods and systems of the present inventiondisclosed herein without departing from the spirit and scope of theinvention. By way of non-limiting example, it will be understood thatthe block diagrams included herein are intended to show a selectedsubset of the components of each apparatus and system, and each picturedapparatus and system may include other components which are not shown onthe drawings. Additionally, those with ordinary skill in the art willrecognize that certain steps and functionalities described herein may beomitted or re-ordered without detracting from the scope or performanceof the embodiments described herein.

The various illustrative logical blocks, modules, circuits, andalgorithm steps described in connection with the embodiments disclosedherein may be implemented as electronic hardware, computer software, orcombinations of both. To illustrate this interchangeability of hardwareand software, various illustrative components, blocks, modules,circuits, and steps have been described above generally in terms oftheir functionality. Whether such functionality is implemented ashardware or software depends upon the particular application and designconstraints imposed on the overall system. The described functionalitycan be implemented in varying ways for each particular application—suchas by using any combination of microprocessors, microcontrollers, fieldprogrammable gate arrays (FPGAs), application specific integratedcircuits (ASICs), and/or System on a Chip (SoC)—but such implementationdecisions should not be interpreted as causing a departure from thescope of the present invention.

The steps of a method or algorithm described in connection with theembodiments disclosed herein may be embodied directly in hardware, in asoftware module executed by a processor, or in a combination of the two.A software module may reside in RAM memory, flash memory, ROM memory,EPROM memory, EEPROM memory, registers, hard disk, a removable disk, aCD-ROM, or any other form of storage medium known in the art.

The methods disclosed herein comprise one or more steps or actions forachieving the described method. The method steps and/or actions may beinterchanged with one another without departing from the scope of thepresent invention. In other words, unless a specific order of steps oractions is required for proper operation of the embodiment, the orderand/or use of specific steps and/or actions may be modified withoutdeparting from the scope of the present invention.

1-28. (canceled)
 29. A computer-implemented method comprising:receiving, by a secure processor of a consumer device, a securetransaction request from a non-secure processor of the consumer device;instructing, by the secure processor, one or more non-secure componentsof the consumer device to operationally connect to the secure processor,and to operationally disconnect from the non-secure processor;generating, by the secure processor, a transaction information messagecomprising one or more values associated with a transaction; sending, bythe secure processor, the transaction information message to a merchantserver indicated in the secure transaction request; and receiving, bythe secure processor, from the merchant server a transaction completionmessage when a first value in the transaction information messagesatisfies a merchant-expected value according to the merchant server anda second value in a copy of the transaction information messagesatisfies a bank-expected value according to a bank device.
 30. Themethod of claim 29, wherein the transaction information messagecomprises a plurality of values, and wherein at least one value of theplurality of values is selected from a group comprising: an amount ofthe transaction, a currency, a hash of a merchant identifier, andtransaction details.
 31. The method of claim 30, wherein the merchantserver transmits the copy of the transaction information message to thebank device when the first value of the at least one value in thetransaction information message satisfies the merchant-expected value.32. The method of claim 29, wherein the bank device determines whetheran account identified in the transaction information message hassufficient funds.
 33. The method of claim 29, further comprising:generating, by the secure processor, a digital signature for thetransaction information message using an encryption key that identifiesthe consumer device; and digitally signing, by the secure processor, thetransaction information message using the digital signature.
 34. Themethod of claim 33, wherein the merchant server determines whether thedigital signature of the transaction information message received fromthe consumer device satisfies a merchant-expected signature.
 35. Themethod of claim 33, wherein the bank device determines whether a seconddigital signature of the copy of the transaction information messagereceived from the merchant server satisfies a bank-expected signature.36. The method of claim 35, wherein digitally signing the transactioninformation message further comprises: transmitting, by the secureprocessor, a request to a credit card reader to digitally sign thetransaction information message according to the bank-expectedsignature; and receiving, by the secure processor, the transactioninformation message having the digital signature from the credit cardreader.
 37. The method of claim 29, further comprising establishing, bythe secure processor, a secure connection with the merchant serveraccording to an encryption algorithm, wherein data packets communicatedvia the secure connection are encrypted according to the encryptionalgorithm.
 38. The method of claim 29, further comprising:authenticating, by the secure processor, a merchant certificate receivedfrom the merchant server; displaying, by the secure processor, via ascreen of the consumer device at least a subset of information from themerchant certificate on a predetermined area of the screen; and display,by the secure processor, via the screen transaction details receivedfrom the merchant server.
 39. The method of claim 29, furthercomprising: executing, by the non-secure processor, a browserapplication having a user interface that communicates user inputs to themerchant server; and receiving, by a non-secure processor, via the userinterface a user input that instructs the non-secure processor togenerate the secure transaction request.
 40. A computing devicecomprising: a non-secure processor configured to generate a messagecontaining a secure transaction request; a secure processor configuredto: receive the secure transaction request from the non-secureprocessor; instruct one or more non-secure components of the computingdevice to operationally connect to the secure processor, and tooperationally disconnect from the non-secure processor; generate atransaction information message comprising one or more values associatedwith a transaction; send the transaction information message to amerchant server indicated in the secure transaction request; and receivefrom the merchant server a transaction completion message when a firstvalue in the transaction information message satisfies amerchant-expected value according to the merchant server and a secondvalue in a copy of the transaction information message satisfies abank-expected value according to a bank device.
 41. The computing deviceof claim 40, wherein the transaction information message comprises aplurality of values, and wherein at least one value of the plurality ofvalues is selected from a group comprising: an amount of thetransaction, a currency, a hash of a merchant identifier, andtransaction details.
 42. The computing device of claim 41, wherein themerchant server transmits the copy of the transaction informationmessage to the bank device when the first value of the at least onevalue in the message satisfies the merchant-expected value.
 43. Thecomputing device of claim 40, wherein the bank device determines whetheran account identified in the transaction information message hassufficient funds.
 44. The computing device of claim 40, wherein thesecure processor is further configured to: generate a digital signaturefor the transaction information message using an encryption key thatidentifies the computing device; and digitally sign the transactioninformation message using the digital signature.
 45. The computingdevice of claim 44, wherein the merchant server determines whether thedigital signature of the transaction information message received fromthe computing device satisfies a merchant-expected signature.
 46. Thecomputing device of claim 44, wherein the bank device determines whethera second digital signature of the copy of the transaction informationmessage received from the merchant server satisfies a bank-expectedsignature.
 47. The computing device of claim 46, further comprising acredit card reader coupled to the computing device, wherein the secureprocessor is further configured to: transmit a request to a credit cardreader to digitally sign the transaction information message accordingto the bank-expected signature; and receive the transaction informationmessage having the digital signature from the credit card reader. 48.The computing device of claim 40, wherein the secure processor isfurther configured to establish a secure connection with the merchantserver according to an encryption algorithm, wherein data packetscommunicated via the secure connection are encrypted according to theencryption algorithm.
 49. The computing device of claim 40, furthercomprising a screen, wherein the secure processor is further configuredto: authenticate a merchant certificate received from the merchantserver; display via the screen at least a subset of information from themerchant certificate on a predetermined area of the screen; and displayvia the screen transaction details received from the merchant server.50. The computing device of claim 40, wherein the non-secure processoris further configured to: execute a browser application having a userinterface that communicates user inputs to the merchant server; andreceive via the user interface a user input that instructs thenon-secure processor to generate the secure transaction request.